Central processing units (CPUs) used in embedded safety-relevant systems commonly include a pair of CPU cores which independently and coherently run the same instruction and data sequences. The outputs of the cores are compared in real time, and if there is a mismatch which typically indicates an error, an appropriate action can then be taken to handle the error. However, by the time a state difference between the two CPU cores has been determined due to a detection of a difference between the outputs of the two CPU cores, the current internal state of either CPU core may have diverged significantly from the internal state at the time of occurrence of a CPU core-related error.
A conventional embedded safety-relevant system addresses these CPU core-related errors by placing the entire system into a reset state, then restarting the entire system. More specifically, in a conventional system a system manager logic module typically receives the core-related errors, then resets not just the pair of CPU cores, but all of the components associated with the system. However, this procedure typically takes a significant period of time during which the system is unavailable for processing of instructions and data, or I/O functions, for example. For example, the system may be unavailable for several tens of milliseconds, which is not a desirable situation for safety-relevant controllers.
Other more complex systems may use three or more CPU cores in conjunction with a majority voting system used to disable malfunctioning cores. However, although such systems may provide more CPU core availability, such availability is at the expense of additional area, power and/or cost.
It would be desirable to provide a higher percentage of CPU core availability in embedded safety-relevant systems to the task of processing data and instruction sets while still providing efficient and robust detection and correction of CPU core processing errors.